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ABSTRACT 

Although  there  is  a  substantial  amount  of  work  on  formal 
requirements  for  two  and  three-party  key  distribution  pro¬ 
tocols,  very  little  has  been  done  on  requirements  for  group 
protocols.  However,  since  the  latter  have  security  require¬ 
ments  that  can  differ  in  important  but  subtle  ways,  we  be¬ 
lieve  that  a  rigorous  expression  of  these  requirements  can  be 
useful  in  determining  whether  a  given  protocol  can  satisfy 
an  application’s  needs.  In  this  paper  we  make  a  first  step  in 
providing  a  formal  understanding  of  security  requirements 
for  group  key  distribution  by  using  the  NPATRL  language, 
a  temporal  requirement  specification  language  for  use  with 
the  NRL  Protocol  Analyzer.  We  specify  the  requirements 
for  GDOI,  a  protocol  being  proposed  as  an  IETF  standard, 
which  we  are  formally  specifying  and  verifying  in  coopera¬ 
tion  with  the  MSec  working  group. 

1.  INTRODUCTION 

Before  we  can  determine  whether  or  not  a  security  pro¬ 
tocol  satisfies  its  requirements,  it  is  necessary  to  determine 
what  those  requirements  are.  Requirements  are  in  general 
well  understood  for  key  distribution  protocols  involving  two 
or  three  parties,  and  a  number  of  formalizations  of  such  re¬ 
quirements  exist.  But,  they  are  not  as  well  understood  for 
group  key  distribution  protocols,  where  keys  may  possibly 
be  distributed  among  an  arbitrarily  large  group  of  principals 
that  may  join  or  leave  the  group  at  any  time.  In  this  pa¬ 
per  we  attempt  to  fill  this  gap  by  developing  a  set  of  formal 
requirements  for  the  GDOI  group  key  management  proto¬ 
col  [1],  a  protocol  which  we  have  been  formally  specifying 
and  verifying  as  part  of  a  joint  effort  with  the  IETF  MSec 
working  group.  To  do  this,  we  used  the  NPATRL  require¬ 
ments  language  [16] ,  a  temporal  language  for  cryptographic 
protocol  requirements  intended  for  use  with  the  NRL  Pro¬ 
tocol  Analyzer  [10,  11].  What  we  found  as  a  result  of  this 
effort  was  that  requirements  for  group  key  distribution  pro- 
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tocols  were  little  understood,  and  that  as  much  or  more  work 
needed  to  be  put  into  developing  a  set  of  formal  security  re¬ 
quirements  as  into  the  formal  specification  of  the  protocol 
itself.  Moreover,  although  these  requirements  were  devel¬ 
oped  specifically  for  GDOI,  we  believe  that  they  are  generic 
enough  so  that  they  could  be  applied  to  many  other  group 
key  management  protocols  with  the  appropriate  modifica¬ 
tions.  The  added  complexity  of  the  requirements  resulting 
from  the  needs  of  secure  group  communication  has  also  in¬ 
duced  us  to  develop  NPATRL  into  a  full-scale  logic  that 
can  be  used  to  reason  about  requirements  as  well  as  specify 
them.  We  describe  the  logic  and  show  how  it  can  be  applied 
in  simplifying  requirements. 

A  group  key  distribution  protocol  is  one  in  which  a  key  is 
distributed  to  members  of  a  group,  which  may  be  of  arbi¬ 
trary  size  for  some  applications.  This  key  may  be  distributed 
by  the  members  of  the  group  themselves  (as  in  the  Cliques 
protocol  [13]),  by  a  centralized  key  distributor,  or  by  a  col¬ 
lection  of  key  distributors.  Such  protocols  may  support  a 
number  of  different  applications,  such  as  secure  multicast 
and  secure  dynamic  coalitions.  They  usually  must  support 
the  joining  and  leaving  of  members  and  possibly  other  oper¬ 
ations.  They  may  also  put  restrictions  on  joining  members 
having  access  to  old  keys  or  on  leaving  members  having  ac¬ 
cess  to  new  keys. 

Superficially,  group  key  distribution  protocols  seem  to  sat¬ 
isfy  requirements  very  similar  to  pairwise  key  distribution 
protocols.  Both  have  requirements  for  secrecy  (no  one  out¬ 
side  the  group  should  learn  the  key),  authentication  (recip¬ 
ients  of  the  key  should  know  where  it  came  from  and  what 
it  was  intended  for)  and  freshness  (recipients  should  not  be 
tricked  into  accepting  an  old  key).  But  when  we  look  at 
these  requirements  more  closely,  especially  at  secrecy  and 
freshness,  we  see  some  important  differences. 

These  differences  arise  from  the  fact  that  the  notion  of 
“session” ,  which  is  so  important  to  pairwise  protocols,  does 
not  exist,  at  least  not  in  the  same  sense,  for  group  protocols. 
In  a  pairwise  protocol,  a  session  is  determined  by  two  com¬ 
municating  principals  (possibly  three,  if  a  key  server  is  used) 
and  a  key.  Keys  should  not  be  learned  by  any  other  than 
the  two  or  three  communicating  principals,  and  a  key  should 
be  unique  to  a  session.  However,  group  protocols  usually  do 
not  have  such  a  notion  of  individual  sessions  strongly  tied 
to  principals  and  keys.  Instead  the  paradigm  is  of  a  group 
which  principals  may  enter  and  leave.  Keys  may  be  updated 
as  principals  enter  or  leave  a  group,  in  order  that  incoming 
principals  have  no  access  to  old  keys,  or  outgoing  princi- 
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pals  have  no  access  to  new  keys.  But  keys  may  be  updated 
for  other  reasons  as  well  that  have  nothing  to  do  with  the 
composition  of  a  group.  Thus  a  freshness  requirement  that 
specifies  a  unique  key  per  session  will  have  no  meaning  here. 

Likewise,  the  definition  of  ‘secrecy’  also  needs  to  be  re¬ 
considered.  In  a  pairwise  protocol,  all  we  require  is  that  a 
session  key  only  be  known  to  the  principals  involved  in  that 
session.  Whether  or  not  one  of  the  principals  is  dishonest 
and  compromises  the  key  is  not  usually  a  concern,  as  long 
as  it  is  prevented  from  threatening  the  integrity  of  other  ses¬ 
sions.  However,  in  the  case  of  group  protocol,  admitting  a 
dishonest  member  into  a  group  can  introduce  new  risks.  Not 
only  can  the  member  learn  the  group  key  while  it  is  present, 
but  depending  upon  how  the  protocol  is  designed,  it  may 
or  may  not  be  able  to  learn  keys  used  before  it  joined  the 
group,  or  keys  generated  after  it  left. 

The  rest  of  this  paper  is  organized  as  follows.  In  Section 

2  we  give  an  overview  of  the  GDOI  protocol.  In  Section 

3  we  give  an  overview  of  the  NPATRL  logic,  and  describe 
the  normal  form  for  NPATRL  requirements  for  the  NRL 
Protocol  Analyzer.  In  Section  4  we  present  the  NPATRL 
requirements  for  GDOI,  and  we  also  describe  our  system 
for  building  secrecy  requirements.  Section  5  concludes  the 
paper.  In  Appendix  A  we  show  how  we  were  able  to  use  the 
logic  to  remove  recursiveness  from  the  secrecy  requirements 
and  reduce  them  to  normal  form. 


2.  AN  OVERVIEW  OF  GDOI 

The  GDOI  (for  Group  Domain  Of  Interpretation)  proto¬ 
col  [1]  is  intended  to  be  used  with  the  Internet  Key  Exchange 
(IKE)  protocol  [7,  5]  to  allow  a  Group  Controller  and  Key 
Server  (GCKS)  to  distribute  keys  to  members  of  a  group. 
Although  it  does  not  specify  any  mechanisms  such  as  key 
hierarchies  [2]  for  efficiently  distributing  keys  to  group  mem¬ 
bers  or  for  expelling  or  adding  members,  it  is  designed  to  be 
compatible  with  the  use  of  such  techniques.  We  have  been 
working  with  the  IETF  MSec  Working  Group  to  develop 
a  set  of  formal  requirements,  as  well  as  a  formal  analysis, 
in  order  to  demonstrate  the  usefulness  of  formal  methods 
in  the  design  or  cryptographic  protocols  and  in  expediting 
the  standardization  process  by  providing  formal  evidence  of 
soundness. 

GDOI  uses  three  categories  of  keys.  Category  1  keys  are 
the  pairwise  keys  shared  between  the  GCKS  and  potential 
members.  Category  2  keys  are  key-encryption  keys  that  are 
used  to  protect  the  Category  3,  or  traffic  encryption  keys. 

For  GDOI,  the  Category  1  (pairwise)  keys  are  distributed 
via  IKE  Phase  1,  which  is  described  in  [7,  5].  Key-encryption 
keys  and  traffic-encryption  keys  are  created  by  the  GCKS. 
The  GCKS  distributes  these  keys  to  the  group  as  a  whole 
by  a  groupkey-push  message  encrypted  with  the  current  key- 
encryption  key.  The  GCKS  maintains  a  sequence  number 
SEQ  that  is  incremented  every  time  a  new  groupkey-push 
datagram  is  sent.  The  current  value  of  the  sequence  number 
is  included  in  the  groupkey-push  message.  This  allows  group 
members  to  verify  that  a  message  is  not  a  replay  of  one  that 
they  have  already  received.  The  groupkey-push  datagram  is 
also  digitally  signed  by  the  GCKS  using  its  private  key  so 
that  receivers  can  verify  that  it  was  sent  by  the  GCKS  and 
not  by  another  group  member. 

The  groupkey-push  message  appears  as  follows  in  [1]: 


Member 


< -  HDR* ,  SEQ,  SA,  KD,  [CERT,]  SIG 

The  term  HDR*  indicates  that  everything  is  encrypted  after 
the  header,  in  this  case  using  the  current  key  encryption  key. 
SEQ  is  the  sequence  number,  SA  the  security  association  for 
this  key  payload,  which  gives  such  information  as  algorithms 
used,  key  lifetimes,  etc.,  and  KD  the  new  keying  material. 
SIG  is  the  digital  signature  of  the  message,  and  CERT  is  an 
optional  certificate  for  the  signature  key. 

When  a  principal  wants  to  join  a  group,  it  takes  part  in 
a  four-message  groupkey-pull  exchange  with  the  GCKS.  All 
messages  are  encrypted  and  authenticated  with  the  pairwise 
key  shared  between  the  two  principals.  In  the  first  message, 
the  principal  sends  a  request  to  join  the  group,  including  the 
group  identifier  and  a  nonce  Ni  to  help  in  verifying  freshness. 

The  GCKS  responds  with  its  own  nonce  Nr  and  with  the 
group  Security  Association,  which  describes  the  mechanisms 
(e.g.  encryption  algorithms)  and  policies  used  by  the  group. 
It  holds  off  on  sending  the  keying  material  itself  until  it 
can  verify  that  the  request  is  recent.  The  group  member 
responds  with  a  hash  (HASH  (3))  taken  over  the  two  nonces. 
The  GCKS  sends  the  keying  material  and  the  current  value 
of  the  sequence  number  in  the  last  message. 

There  are  also  some  optional  fields  in  the  last  two  mes¬ 
sages.  If  it  is  required  by  the  group  policy,  the  member 
can  send  its  own  part  of  a  Diffie-Hellman  key  exchange  in 
the  third  message  (KE_I),  and  the  GCKS  can  respond  with 
its  part  of  the  exchange  in  the  fourth  message  (KE_R).  The 
resulting  Diffie-Hellman  key  is  used  to  encrypt  the  group 
keying  material  by  use  of  exclusive-or.  The  purpose  of  this 
is  to  provide  perfect  forward  secrecy:  even  if  a  pairwise  key 
is  compromised,  the  intruder  can  learn  only  keys  distributed 
after  the  compromise,  not  those  distributed  before. 

Another  option  allows  the  two  principals  to  verify  that 
each  is  authorized  to  act  in  their  respective  roles.  This  is  the 
proof-of-possession  (POP)  option,  where  each  party  includes 
a  public  key  certificate  signed  by  a  relevant  authority,  and 
proves  his  or  her  possession  of  the  key  by  using  it  to  sign 
the  two  nonces  that  were  exchanged  earlier  in  the  protocol. 

The  four  messages  sent  in  the  groupkey-pull  exchange  ap¬ 
pear  as  follows  in  [1]: 

Initiator  (Member)  Responder  (GCKS) 

HDR*,  HASH(l)  ,  Ni,  ID  - > 

<  -  HDR*,  HASH (2)  ,  Nr,  SA 

HDR*,  HASH(3)  [,  KE_I]  - > 

[,CERT]  [,P0P_I] 

<  -  HDR*,  HASH (4)  ,  [KE_R , ]  SEQ, 

KD  [,CERT]  [,P0P_R] 


where  Ni  and  Nr  are  the  two  nonces,  SA  is  the  security  associ¬ 
ation,  KE_I  and  KE_R  are  the  optional  Diffie-Hellman  halves, 
CERT,  P0P_I,  P0P_R  are  are  the  certificates  and  signatures 
used  in  the  optional  proof-of-possession  exchange,  and  SEQ 
and  KD  are  the  sequence  number  and  keying  material  (en¬ 
crypted  with  the  Diffie-Hellman  key  if  that  is  used),  respec¬ 
tively.  The  notation  HDR*  means,  as  before,  that  all  informa¬ 
tion  after  the  header  is  encrypted,  this  time  with  the  shared 
Category  1  key.  The  hashes  in  the  exchange  are  computed 
over  the  information  sent  in  the  respective  messages.  More 
detail  may  be  found  in  [1]. 

Note  that  in  no  place  does  GDOI  specify  means  for  elimi¬ 
nating  members  from  the  group.  This  is  accomplished  using 


something  called  a  key  hierarchy.  Basically,  a  key  hierarchy 
is  a  tree,  the  root  of  which  is  the  actual  key  used  for  encryp¬ 
tion.  Nodes  of  the  tree  encrypt  and  authenticate  the  nodes 
above  it.  When  a  principal  is  admitted  to  the  group,  it  is 
assigned  a  leaf  of  the  tree.  When  it  leaves  the  group,  only 
the  (limited)  portion  of  the  tree  it  needs  to  compute  the 
group  key  ough  to  be  updated.  This  allows  access  control 
for  both  entering  and  leaving  members  to  be  enforced  in  an 
efficient  way,  as  well  as  providing  extra  security  beyond  that 
provided  by  the  key-encryption  key  used  to  encrypt  the  push 
message,  since  a  new  key  will  be  protected  by  the  keys  below 
it  in  the  hierarchy.  See  [2]  for  a  discussion  and  overview  of 
key  hierarchies. 

3.  THE  NPATRL  LOGIC 

3.1  The  NRL  Protocol  Analyzer  Model 

The  NRL  Protocol  Analyzer,  or  NPA  for  short,  is  a  com¬ 
puter-assisted  verification  tool  for  security  protocols  which 
combines  model  checking  and  theorem-proving  techniques  to 
establish  authentication  and  secrecy  properties.  We  present 
merely  a  brief  overview  here.  The  interested  reader  is  invited 
to  consult  [10,  11]  for  further  details. 

A  protocol  is  modeled  as  a  number  of  communicating  state 
machines,  each  associated  with  a  different  roles.  Their  tran¬ 
sitions  correspond  to  the  actions  that  comprise  the  corre¬ 
sponding  role.  At  run  time,  roles  are  executed  by  honest 
principals  who  faithfully  follow  the  protocol.  Several  in¬ 
stances  can  be  executing  at  the  same  time,  and  they  are 
distinguished  by  means  of  a  unique  round  number.  The 
intruder  is  modeled  after  the  Dolev-Yao  adversary  [4],  Dis¬ 
honest  principals  share  their  keys  and  other  confidential  in¬ 
formation  with  the  adversary. 

The  messages  in  transit,  the  information  held  by  each 
principal  and  the  intruder,  the  runs  currently  being  exe¬ 
cuted,  and  the  point  that  each  of  them  has  reached  consti¬ 
tute  the  global  state  for  the  NPA.  A  protocol  action  imple¬ 
ments  a  local  transformation  with  global  effects  on  the  state. 
The  initial  state  is  implicit  in  the  protocol  specification. 

In  order  to  verify  a  protocol,  a  specification  is  fed  into 
the  run-time  system  of  the  NRL  Protocol  Analyzer  together 
with  the  description  of  a  family  of  states  that  correspond 
to  attack  situations.  The  system  applies  protocol  actions 
backwards  from  these  target  states  until  it  either  reaches  the 
initial  state,  or  it  exhausts  all  possibilities  for  doing  so.  As  it 
regresses  back  towards  the  initial  state,  the  NPA  maintains 
a  trace  of  the  sequence  of  actions  that,  when  executed,  lead 
to  the  target  state.  If  the  initial  state  is  ever  reached,  the 
resulting  trace  is  a  potential  attack.  If  all  possibilities  are 
exhausted,  there  is  no  attack  of  the  kind  sought.  Although 
the  search  space  is  in  general  infinite,  the  NPA  incorporates 
techniques  based  on  theorem  proving  that  have  the  effect 
of  soundly  restricting  the  search  to  a  finite  abstraction,  in 
most  cases. 

Traces  are  sequences  of  events  of  the  following  form: 
event(P ,  Q,  T,  L,  N) 

In  general,  any  protocol  or  intruder  state  transition  may  be 
assigned  an  event.  The  arguments  are  interpreted  as  follows: 
P  is  the  principal  executing  the  transition,  Q  is  the  set  of 
the  other  parties  involved  in  it,  T  is  a  name  that  identifies 
the  transition,  L  is  a  set  of  relevant  words,  and  N  is  the 
local  round  number  of  the  transition.  Typical  categories  of 
events  correspond  to  receiving  a  message,  accepting  data  as 


valid  as  a  result  of  performing  certain  checks  and  sending  a 
message.  For  example: 

et>ent(user(A ,  honest),  [user(B,  H)].  initiator_accept_key,  [A],  N) 

This  event  describes  the  execution  of  a  transition  called 
“initiator_accept_key”  by  honest  principal  A  that  involves  a 
key  K  and  some  other  principal  B  who  may  or  may  not  be 
honest. 

3.2  The  NPATRL  Syntax 

The  NRL  Protocol  Analyzer  has  successfully  analyzed  a 
number  of  protocols,  sometimes  uncovering  previously  un¬ 
known  flaws  [10,  11].  But,  secrecy  and  authentication  goals 
are  awkwardly  expressed,  as  states  that  should  not  be  reach¬ 
able  from  the  initial  state.  This  unintuitive  and  occasionally 
error  prone  way  of  writing  requirements  would  have  made  it 
very  difficult  to  use  the  NPA  for  large  protocols. 

The  NRL  Protocol  Analyzer  Temporal  Requirements  Lan¬ 
guage,  better  known  as  NPATRL  (and  pronounced  “N  Pa¬ 
trol”  ) ,  was  designed  to  address  these  shortcomings  [16] .  This 
formalism  makes  available  the  abstract  expressiveness  of  a 
logical  language  to  specify  requirements  at  a  high  enough 
level  to  capture  intuitive  goals  precisely,  and  yet  it  can  be 
interpreted  in  the  NPA  search  engine. 

NPATRL  requirements  are  logical  expressions  whose  ato¬ 
mic  formulas  are  event  statements,  which  mostly  correspond 
to  events  in  the  NRL  Protocol  Analyzer;  they  include  events 
denoting  actions  by  honest  principals  that  can  be  found  in 
the  trace  of  an  NPA  search,  and  the  special  learn  event  that 
indicates  the  acquisition  of  information  by  the  adversary. 
NPATRL ’s  syntax  for  events  is  similar  but  not  identical  to 
the  NPA’s.  In  NPATRL,  the  NPA  accept  event  given  above 
is  written: 

initiator_accept_key(user(A,  honest),  user(R,  H),  K,  N) 

The  logical  infrastructure  of  NPATRL  consists  of  the  usual 
connectives  A,  — >,  etc,  and  the  temporal  modality  <8> 
which  is  interpreted  as  “happened  at  some  time  before”  or 
“previously” . 

For  example,  we  may  have  the  following  requirement: 

If  an  honest  principal  A  accepts  a  key  I\  for  com¬ 
municating  with  another  honest  principal  B,  then  a 
server  must  have  previously  generated  and  sent  this 
key  with  the  idea  that  it  should  be  used  for  communi¬ 
cations  between  A  and  B,  and  that  both  are  expected 
to  be  honest. 

We  can  use  NRL  Protocol  Analyzer  events  to  construct  an 
NPATRL  formula  that  expresses  it: 

initiator  _accept_key(user(A,  honest),  user(B,  H),  K ,  N) 

— >  <§•  svr_send_key(server,  (user(A,  honest),  user(R,  honest)),  K,  N ) 

This  formula  is  a  simple  expression  of  the  above  requirement. 

Intuitively,  the  protocol  verification  process  changes  from 
what  we  discussed  in  the  previous  section  by  using  NPATRL 
requirements  where  the  final  state  appeared.  More  precisely, 
we  first  need  to  map  every  NPATRL  event  statement  to  an 
actual  event  in  the  NPA  specification  of  the  protocol.  Then, 
we  take  the  negation  of  each  NPATRL  requirement  as  a 
way  to  characterize  the  states  that  should  be  unreachable 
if  and  only  if  that  requirement  is  satisfied.  At  this  point, 
we  perform  the  analysis  as  in  the  previous  section:  if  the 
NPA  proves  that  this  goal  is  unreachable,  the  protocol  sat¬ 
isfies  the  original  requirement.  Otherwise,  it  returns  a  trace 


corresponding  to  an  attack  on  the  protocol  that  potentially 
invalidates  the  requirement. 

A  couple  of  particular  points  about  NPATRL  expressions: 
Events  occur  exactly  once.  This  means  that  atomic  formu¬ 
las  are  true  at  exactly  one  point  in  a  trace  (if  at  all) .  There 
is  nothing  in  NPATRL  syntax  to  automatically  guarantee 
this  uniqueness;  it  is  assumed  that  event  statements  con¬ 
tain  enough  individuating  information  in  their  arguments 
or  predicate  to  enforce  this.  Note  that  NPA  guarantees  this 
uniqueness,  in  part  by  having  all  events  indexed  both  by  lo¬ 
cal  runs  and  timestamps.  Second,  “<£”  is  a  strict  operator; 
it  includes  times  prior  to  the  present  time  but  does  not  in¬ 
clude  the  present  time.  It  is  also  convenient,  especially  when 
stating  axioms,  to  have  the  dual  operator  in  our  language, 
“B” ,  read  as  “at  all  previous  times”  or  “always  previously” . 
It  can  be  defined  logically  by,  B  tp  <->  -iO-k p,  where  tp  is  an 
formula. 

NPATRL  has  been  extensively  used  in  the  last  few  years 
to  analyze  protocols  with  various  characteristics.  Among 
these,  generic  requirements  have  been  given  for  two-party 
key  distribution  protocols  [14,  15]  and  two-party  key  agree¬ 
ment  protocols  [16].  The  most  ambitious  specification  un¬ 
dertaken  using  NPATRL  has  involved  the  requirements  of 
the  credit  card  payment  transaction  protocol  SET  (Secure 
Electronic  Transactions)  [9].  SET  proved  particularly  dif¬ 
ficult  to  specify  for  several  reasons.  One  of  these  was  that 
the  objects  to  be  authenticated  are  dynamic:  unlike  keys, 
what  is  agreed  upon  changes  as  it  passes  from  one  principal 
to  another.  This  exercise  revealed  several  ambiguities  [9[. 

Our  current  task,  formalizing  group  key  management  re¬ 
quirements,  has  its  own  dynamics.  Even  when  the  data 
objects  (keys)  are  constant,  the  principals  sharing  them  are 
not.  And  the  very  notion  of  a  session  is  much  less  well 
defined  than  in  previously  studied  cases.  Perhaps  most  sig¬ 
nificantly,  until  this  point  we  had  been  able  to  use  NPATRL 
as  just  a  language.  All  statements  were  interpreted  into  the 
NPA  and  evaluated  there.  However,  we  have  found  it  neces¬ 
sary  to  reason  at  the  level  of  NPATRL  itself.  This  requires 
a  logic  for  our  logical  language. 

3.3  NPATRL  Axioms 

We  give  axioms  of  a  normal  modal  logic  adequate  to  cap¬ 
ture  the  needed  temporal  reasoning.  Readers  are  referred  to 
standard  texts  for  details  on  systems  of  modal  and  temporal 
logic  [3,  6,  8]. 

Our  logic  has  two  inference  rules: 

Modus  Ponens:  From  tp  and  tp  — >  ip  infer  ip. 
Necessitation:  From  b  tp  infer  b  B tp. 

‘b’  is  a  metalingusitic  symbol.  T  b  p ’  means  that  tp  is  deriv¬ 
able  from  the  set  of  formulae  T  (and  the  axioms  as  stated 
below).  4b  tp ’  means  that  tp  is  a  theorem,  i.e. ,  derivable 
from  axioms  alone.  Axioms  are  all  instances  of  tautologies 
of  classical  propositional  logic,  and  all  instances  of  the  fol¬ 
lowing  axiom  schemata 

K  B(i p  — *  ip)  — *  (B tp  — >  B tp) 

4  B tp  — >  BB tp 
W  B(B:p  — >  tp)  — >  B tp 

L  B((y>  A  B tp)  —>■  ip)  V  H ((tp  A  B^)  — >  tp) 

The  first  axiom  guarantees  that  our  temporal  operators  re¬ 
spect  the  non-temporal  part  of  the  logic.  The  second  one 


guarantees  that  temporal  reasoning  is  transitive.  The  third 
guarantees  that  sets  of  events  are  always  finite  and  strictly- 
ordered.  The  last  guarantees  that  events  are  weakly-connec¬ 
ted  (comparable).  Note  that  in  the  presence  of  K  and  W, 
the  4  axiom  becomes  redundant.  We  have  explicitly  in¬ 
cluded  it  because  we  specifically  use  transitivity  in  our  ar¬ 
guments  in  appendix  A.  There  is  some  discussion  of  logics 
containing  these  axioms  in  [6]  and  [8].  In  [8],  axiom  L  is 
called  “Lemo”  after  Lemmon.  Space  limitations  preclude  a 
more  detailed  presentation  here. 

3.4  NPA  Acceptable  Expressions 

Although  NPATRL  was  originally  designed  to  be  used 
with  the  NRL  Protocol  Analyzer,  it  is  actually  much  more 
expressive  than  the  set  of  specifications  accepted  by  the  tool. 
Thus,  in  order  to  make  NPATRL  usable  with  NPA,  it  is  nec¬ 
essary  to  identify  a  subset  of  NPATRL  requirements  that  are 
acceptable  by  NPA,  and  to  put  them  into  a  normal  form  that 
is  parsable  by  NPA. 

An  NRL  Protocol  Analyzer  query  can  be  specified  in  terms 
of  three  things:  terms  known  by  the  intruder,  values  of  local 
state  variables,  and  sequences  of  events  that  did  or  did  not 
occur.  The  part  of  the  query  concerning  sequences  of  events 
corresponds  most  closely  to  the  NPATRL  events.  However, 
these  events  only  correspond  to  user  actions,  and  do  not  in¬ 
clude  learn  events,  which  correspond  to  intruder  actions.  In 
order  to  capture  intruder  learn  events,  we  will  need  to  make 
use  of  the  part  of  the  query  that  specifies  terms  known  by 
the  intruder.  This  can  cause  some  difficulties,  since  an  NPA 
query  does  not  specify  when  the  terms  were  learned  by  the 
intruder.  However,  we  can  simplify  matters  by  limiting  our¬ 
selves  to  queries  which  specify  the  learning  of  only  one  term. 
This  is  usually  adequate,  and  when  it  is  not,  we  can  usually 
transform  the  NPATRL  requirement  using  our  logic  so  that 
the  restriction  is  satisfied. 

Given  that,  we  specify  a  normal  form  R  for  NPA  accept¬ 
able  expressions  in  a  BNF  grammar  as  follows.  We  let  w 
stand  for  any  learn  event,  a  stand  for  any  atomic  event  that 
is  not  a  learn  event,  and  let  b  stand  for  any  atomic  event. 
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4. 

REQUIREMENTS 

FOR  GDOI 

4.1  Assumptions 

We  assume  that  each  group  is  managed  by  one  GCKS  (it 
is  possible  to  have  more,  but  the  means  for  doing  this  are 
not  specified  in  the  GDOI  document).  We  assume  that  a 
GCKS  may  manage  more  than  one  group,  and  that  a  mem¬ 
ber  may  belong  to  more  than  one  group.  We  assume  that 
members  may  both  join  and  leave  a  group,  and  a  member 
may  have  concurrent  and/or  overlapping  memberships  in 
the  same  group. 

We  assume  the  usual  Dolev-Yao  style  intruder,  who  can 
read,  alter,  destroy,  and  create  traffic,  and  is  in  league  with 
any  dishonest  principals,  who  share  all  data  with  it.  We 
assume  that  all  GCKSs  are  honest,  but  that  some  members 
may  be  dishonest.  Note  that  as  a  result  of  this  assumption 
we  make  no  distinction  between  the  intruder’s  learning  a 


key  and  a  principal  learning  a  key  to  which  it  is  not  entitled. 
Only  dishonest  principals  will  attempt  to  gain  access  to  keys 
to  which  they  are  not  entitled,  and  dishonest  principals  are 
assumed  to  share  all  information  with  the  intruder. 

We  assume  that  there  are  two  ways  in  which  a  key  can  be 
compromised  that  cannot  be  prevented  by  the  protocol.  One 
is  by  stealing:  the  intruder  may  learn  the  key  by  cryptanal¬ 
ysis,  theft,  etc.  even  if  all  possessors  of  the  key  are  honest. 
The  other  is  by  having  a  dishonest  member  join  the  group. 

Finally,  in  order  to  simplify  matters,  we  only  define  events 
and  requirements  for  key  encryption  keys,  not  traffic  encryp¬ 
tion  keys.  Since  traffic  encryption  keys  are  protected  by  key 
encryption  keys  and  distributed  via  the  same  mechanisms,  it 
should  be  relatively  straightforward  to  derive  their  require¬ 
ments  from  the  requirements  for  key  encryption  keys. 

4.2  GDOI  Events 

In  general,  events  map  to  actual  messages  and  vice  versa. 
However,  since  the  central  messages  of  the  groupkey-pull 
exchange  simply  defer  computation  in  order  to  resist  forms 
of  denial-of-service  attacks  [12]  and  the  NPA  does  not  cur¬ 
rently  support  reasoning  about  denial-of-service,  we  behave 
as  if  their  information  load  were  compounded  with  the  outer 
messages  of  this  exchange. 

We  divide  the  possible  GDOI  events  according  to  the  prin¬ 
cipals  that  engage  in  them.  There  are  four  types  of  princi¬ 
pals:  the  intruder,  the  GCKS,  the  group  member,  and  an  au¬ 
thorization  server  responsible  for  issuing  credentials.  Since 
a  group  member  may  be  honest  or  dishonest,  we  represent 
a  general  group  member  as  member(M,  H),  an  honest  mem¬ 
ber  as  member(M,  honest),  and  a  dishonest  group  member 
as  member(M,  dishonest). 

4. 2. 1  Intruder  Events 

There  is  only  one  intruder  event  of  interest  to  us  here: 
the  event  in  which  the  intruder  P  learns  a  word  W.  We 
represent  that  as  follows: 

learn  (P,  (),  W,  N) 

4.2.2  Authorization  Server  Event 

The  authorization  server  is  responsible  only  for  issuing 
credentials  to  principals.  In  order  to  simplify  matters,  we 
assume  that  each  group  has  its  own  set  of  credentials  appro¬ 
priate  to  it. 

This  action  is  represented  by 

auth  Jssuecreds (AUTH,  X,  (C,  G),  N) 

where  X  is  the  principal  to  whom  the  credentials  are  issued, 
C  stands  for  the  credentials,  and  G  is  the  group  to  which 
the  credentials  apply. 

4.2.3  The  GCKS 

The  GCKS  performs  a  number  of  actions  of  interest.  It 
can  create  a  key  encryption  key.  It  can  admit  and  expel 
members.  It  can  also  cause  a  key  to  become  current,  and 
cause  a  key  to  expire.  It  can  send  a  key,  either  in  response 
to  a  member’s  request,  or  as  part  of  a  group-key  push  data¬ 
gram.  We  represent  these  as  follows: 

Creating  a  key: 

gcks_createkey(GCKS ,  (),  (G,  Kq),  N) 

where  G  is  the  group  for  which  GCKS  is  creating  the  key 
encryption  key,  Kg- 


Sending  a  key  as  a  result  of  a  pull  exchange: 

gcks_sendpu  II  key  (GCKS,  M,  (. KG,NM ,  NGm,  G,  Kgm),  N) 

where  M  is  the  member,  Kg  is  the  key,  G  is  the  group,  Kgm 
is  the  pairwise  key,  Nm  is  the  nonce  M  uses  in  initiating 
the  exchange  and  Ngm  is  the  nonce  G  uses  in  responding. 
We  also  use  the  gcks_sendpullkey  event  to  cover  the  GCKS’s 
admitting  M  to  the  group,  since  M  requests  membership 
by  initiating  a  pull  protocol.  We  use  Ngm  to  identify  M’s 
particular  membership  in  the  group.  Note  that  this  may 
not  be  the  identifier  used  in  a  real  application  (as  a  mat¬ 
ter  of  fact,  GDOI  does  not  specify  any  kind  of  membership 
identifier);  however  it  is  useful  from  a  requirements  point  of 
view  in  that  it  allows  us  to  distinguish  between  different  and 
possibly  overlapping  memberships  on  the  part  of  the  same 
individual. 

Sending  a  key  in  a  push  message: 

gcks_sendpushkey(GCKS,  (),  (G,  Kg,K'g),  N) 

The  event  gcks_sendpushkey  causes  one  key,  K'g,  to  expire 
for  group  G  and  causes  the  next  one  Kg  to  become  current. 
The  initial  key  created  for  a  group  is  first  sent  in  a  pull- 
key  message.  Except  for  such  initial  keys,  we  assume  for 
convenience  that  a  push-key  message  making  Kg  current  is 
sent  immediately  after  the  create  event  that  produced  Kg 
(without  the  possibility  of  an  intervening  distribution  in  a 
pull- key  message).  We  also  assume  that  the  initial  key  is 
sent  in  at  least  one  pull-key  response  that  takes  place  im¬ 
mediately  after  its  creation.  We  say  the  initial  key  becomes 
current  when  that  first  pull-key  response  containing  it  is 
sent. 

We  note  that  neither  gcks_sendpullkey  nor  gcks_sendpushkey 
tell  the  whole  story  about  the  keying  material  passed  in 
these  two  messages.  In  actual  fact,  the  pull-key  message 
will  contain,  not  only  the  current  key,  but  also  the  relevant 
part  of  the  key  hierarchy  that  the  member  M  needs  to  ac¬ 
cess  the  key.  Likewise  the  gcks_sendpushkey  message  will 
also  contain  the  portion  of  the  key  hierarchy  that  needs  to 
be  changed  to  give  members  access  to  the  new  key  and  pre¬ 
vent  former  members  from  accessing  the  new  key,  if  this  is 
desired. 

Canceling  a  membership: 

gcks_cancel (GCKS.  M,  (G,  NGM),N) 

where  M  is  the  member,  G  is  the  group,  and  Ngm  identi¬ 
fies  the  membership.  Note  that  expulsion  cancels  only  the 
membership  with  identifier  Ngm,  not  all  memberships  of 
that  member.  In  order  to  truly  expel  the  member,  all  its 
memberships  would  have  to  be  canceled. 

We  note  that  gcks_cancel  would  be  achieved  in  GDOI  by 
having  the  GCKS  send  out  a  push  message  containing  a  new 
key  hierarchy  from  which  M  is  excluded.  We  choose  to  spec¬ 
ify  gcks_cancel  separately  from  gcks_sendpushkey  since  this 
allows  us  to  avoid  issues  such  as  canceling  multiple  mem¬ 
berships  in  one  message,  etc. 

Sending  a  POP: 

gcks_sendpop( GCKS,  M,  (G,  NGm ,  NM,  Ca),N) 

This  event  describes  a  GCKS  sending  a  POP  in  response  to 
a  members  request.  Cg  stands  for  G’ s  credentials. 


Stealing  a  Key: 

Finally,  we  need  to  specify  the  stealing  of  a  key.  We  think  of 
this  not  as  something  done  by  the  intruder,  but  as  something 
done  by  the  GCKS.  In  other  words,  the  action  of  stealing 
a  key  needs  to  be  precipitated  by  the  GCKS  “losing”  a  key. 
This  appears  paradoxical,  but  it  is  a  result  of  our  model’s 
assumption  that  actions  involving  a  piece  of  data  can  only 
be  initiated  by  those  in  possession  of  it.  Note  that  we  could 
also  include  actions  describing  members  losing  keys,  but  that 
this  would  be  redundant. 

We  have  two  event  statements,  one  describing  the  loss  of  a 
key-encryption  key,  and  one  describing  the  loss  of  a  pairwise 
key: 

gcksJosegroupkey(GGK5',  (),  (G,  Kg),  N) 
where  G  is  the  group  and  Kq  is  the  key. 

gcks Josepa i rwisekey ( G CKS,  (),  {GCKS,  M,  KGM),  N) 

where  Kgm  is  the  pairwise  key  and  M  is  the  member  who 
shares  the  key  with  the  GCKS. 

4.2.4  Member  Actions 

The  relevant  member  actions  involve  accepting  a  key  and 
requesting  a  key.  A  member  can  only  request  a  key  by  ini¬ 
tiating  a  group- key  pull  exchange,  but  it  may  accept  a  key 
as  a  result  of  receiving  the  final  message  of  a  group-key  pull 
exchange  or  as  a  result  of  receiving  a  group-key  push  mes¬ 
sage. 

The  events  are  specified  as  follows. 

Requesting  a  Key: 

member_requestkey(M,  GCKS,  (G,  Nm ,  Kqm),  N) 
where  GCKS  is  the  GCKS,  G  is  the  group,  Nm  is  the  nonce 
M  uses  in  initiating  the  request  (to  distinguish  it  from  other 
requests),  and  Kgm  is  the  pairwise  key  shared  between 
GCKS  and  M.  This  corresponds  to  M  sending  the  first 
message  in  a  group-key  pull  exchange. 

Accepting  a  Key  From  a  Group-key  Pull  Exchange: 
member_acceptpullkey(M,  GCKS,  (G,  Kq,Ngm,  Km,  Kgm),  N) 
where  GCKS  is  the  GCKS,  G  is  the  group,  Kg  is  the  key, 
and  Kqm  is  the  pairwise  key  shared  between  M  and  the 
GCKS.  Again,  this  does  not  give  the  whole  picture,  as  it 
leaves  out  the  portion  of  the  key  hierarchy  that  the  GCKS 
sends  to  M. 

Accepting  a  Key  From  a  Group-key  Push  Message: 

member_acceptpushkey(M,  GCKS ,  (G,  Kg,  Kq),  N) 
where  GCKS  is  the  GCKS,  G  is  the  group,  Kg  is  the  new 
key,  and  K'a  is  the  current  key  encryption  key.  Again,  we 
leave  out  the  portion  of  the  key  hierarchy  that  M  uses  to 
authenticate  the  message  and  decrypt  Kg- 
For  conciseness,  we  set 
member_acceptkey(M,  GCKS ,  (G,  Kg),  N) 

<->  member_acceptpullkey(M,  GCKS ,  (G,  Kq,  -,  -),  N) 

V  member_acceptpushkey(M,  GCKS,  (G,  Kq,  — ),  K) 

Here  and  in  the  rest  of  this  paper,  we  write  for  an  argu¬ 
ment  whose  actual  value  is  irrelevant.  Each  occurrence  can 
be  thought  of  as  a  distinct  variable. 

Sending  a  POP: 

member_sendpop(M,  GCKS,  (G,  NM,NGM,CM),  N) 

This  event  describes  a  member  M  sending  a  POP  in  re¬ 
sponse  to  a  GCKS’s  request.  Cm  stands  for  M’s  credentials. 


4.3  Authentication  Requirements 

Since  GDOI  is  only  intended  to  address  the  problem  of 
secure  distribution  of  group  keys,  not  the  authentication  of 
group  members  to  each  other,  its  authentication  require¬ 
ments  are  simple  and  rather  similar  to  those  for  two-party 
protocols.  Thus  we  give  them  first.  There  are  authentication 
requirements  for  both  the  group  member  and  the  GCKS. 
The  group  member  will  want  to  know,  if  it  accepts  a  key, 
that  that  key  was  generated  by  the  GCKS  for  that  group. 
The  GCKS  will  want  to  know  that,  if  it  sends  a  key  to  a 
group  member,  then  that  group  member  requested  a  key. 
Finally,  there  are  authentication  requirements  on  the  proof 
of  possession  (POP)  algorithm.  If  the  GCKS  accepts  a  proof 
of  possession  from  a  group  member,  then  the  group  mem¬ 
ber  should  have  obtained  the  appropriate  authorizations  and 
the  group  member  should  have  responded  to  the  GCKS’s  re¬ 
quest  for  a  POP.  A  similar  requirement  holds  for  the  group 
member’s  accepting  a  POP  from  the  GCKS.  We  consider 
the  three  types  of  authentication  below. 

4.3.1  Authentication  of  a  Key  to  a  Group  Member 

Since  there  are  two  different  ways  a  group  member  can 

receive  a  key,  we  have  two  different  sets  of  requirement.  In 
the  case  of  the  group  member  M  accepting  a  key  Kg  for 
group  G  as  a  result  of  the  pull  protocol,  we  require  that  one 
of  two  things  must  have  happened;  either  the  pairwise  key 
shared  between  the  member  and  the  GCKS  was  lost,  or  the 
GCKS  did  send  Kg  to  M  for  use  in  G: 

member_acceptpullkey(M,  GCKS,  (G,  Kq,  Nm,  Nqm,  Kgm),  -) 
— >  OgcksJosepairwisekey)  GCKS,  (),  (M,  Kqm),  —) 

V  <$>gcks_sendpullkey(  GCKS,  M,  (Kg,  -  G,  KGM),  _) 

In  the  case  of  the  member  M  accepting  the  key  Kq  for 
group  G  as  the  result  of  receiving  a  push  datagram,  we  again 
require  that  the  GCKS  has  sent  Kg  for  use  in  G  in  a  push 
datagram  protected  by  key  K'a\ 

member_acceptpushkey(M,  GCKS,  (G,  Kq,  Kq),  _) 

— >  Ogcks_sendpushkey(GCK5,  (),  (G,  Kq,  Kq),  _) 

Observe  that  this  requirement  does  not  make  any  provision 
for  losing  an  old  group  key  Kq  since  gcks_sendpushkey  mes¬ 
sages  are  authenticated  with  the  signature  of  the  GCKS. 

4.3.2  Authentication  of  a  Group  Member’s  Request 

Although  the  GCKS  has  two  ways  of  sending  keys,  it  has 

only  one  way  of  sending  a  key  to  a  specific  group  member: 
via  a  pull  protocol.  Thus  we  need  only  one  requirement  here, 
saying  that  if  the  GCKS  sent  a  key  to  a  group  member  in 
response  to  a  pull  protocol  request,  then  either  the  pair¬ 
wise  key  between  the  GCKS  and  group  member  was  lost, 
or  the  group  member  actually  sent  that  request.  We  need  a 
unique  way  of  identifying  the  group  member’s  request,  and 
so  we  will  use  the  nonce  the  group  member  sends  in  the  first 
message  of  the  pull  protocol: 

gcks  .send  pu  II  key  (GGKS,  M,  ( KG,NM ,  NGm,G,  KGm),  -) 

— >  Ogcks_losepairwisekey(GGKS',  (),  (M,  Kqm),  -) 

V  Omember_requestkey(M,  GCKS,  (G,  Nm,  Kqm),  -) 

4.3.3  Authentication  of  a  Proof  of  Possession 

For  proofs  of  possession,  we  want  to  show  that,  for  either 
the  GCKS  or  a  member,  if  A  accepts  a  key  requiring  a  proof 
of  possession  from  B,  then  B  sent  the  POP  in  response  to 


A’s  request,  and  B  obtained  the  credentials  from  the  appro¬ 
priate  authority.  The  act  of  obtaining  credentials  is  outside 
the  scope  of  GDOI;  however,  we  leave  it  in  the  requirement 
specification  because  it  is  clearly  the  intent  of  the  POP. 

gcks_sendpullkey(GCA,S,  M,  (AG,  Nm,Ngm,G ,  Kgm),_) 

(  member_sendpop(M,  GCKS,  (G,  NM ,  NGM,  M,  CM),  -) 
A  Oauth  _issuecreds(AI/T H,  M,  ( CM,  G ),  _)) 

member_acceptpjllkey(M,  GCKS ,  (KG,  Nm ,  NGm,G,  KGm),  -) 

-»0  (  gcks_sendpop(GCKS ,  M{G,  NM ,  Ngm,Cm),  -) 

A  Oauth .issuecreds {AUTH,  M,  (CM,  G),  _)) 

4.4  Freshness  Requirements 

For  GDOI,  we  can  identify  two  types  of  freshness.  One, 
we  call  recency  freshness.  This  is  the  requirement  that,  if  a 
principal  receives  a  piece  of  information,  such  as  a  key,  then 
it  must  have  been  current  at  some  specified  point  in  time 
according  to  the  principal’s  local  clock,  for  example  when 
the  principal  requested  it.  The  other,  we  call  sequential 
freshness.  This  is  the  requirement  that,  if  a  principal  accepts 
a  key  KG,  then  it  could  not  have  previously  accepted  a  key 
that  became  current  after  KG. 

4.4.1  Recency  Freshness  for  Pull  Protocol 

member_acceptpullkey(M,  GCKS ,  (G,  NM,NGM,  K'G,  KGM),  N) 
— >  OgcksJosepairwisekey(GCA.S,  (),  (M,  KGm ),  — ) 

V -i(0  (  member_requestkey(Af,  GCKS,  (G,  Nm ,  KGm),  N) 
A  Ogcks_sendpushkey(GGAS,  (),  (G,  KG,  K'G),  _))) 

Note  that  the  definition  of  recency  freshness  is  one  of  the 
few  places  we  make  use  of  round  numbers,  since  the  member 
requests  and  accepts  the  key  in  the  same  round.  Note  also 
that  the  GCKS’s  act  of  sending  a  key  KG  protected  by  K'G 
using  the  push  protocol  results  in  the  expiration  of  KG. 

4.4.2  Sequential  Freshness  for  Pull  Protocol 

member_acceptpjllkey(M,  GCKS ,  (G,  Nm,  NGm,  Kg,  KGm),  -) 
— >  Ogcks_losepairwisekey(GCAS,  (),  (M,  KGm),  — ) 

V  (  member_acceptkey(M,  GCKS,  (G,  K'G),  _) 

A  O  (  gcks_createkey(GGi:f5',  (),  (G,  K'G),  _) 

A  <S>gcks_createkey(  GCKS,  (),  (G,  KG),  _))) 

Recall  from  Section  4.2.3  that  a  group  key  is  sent  (and 
therefore  made  current)  immediately  after  it  is  created  by 
the  GCKS. 

4.4.3  Sequential  Freshness  for  Push  Protocol 

member_acceptpushkey(A/,  GCKS,  (G,  I\G,  K'G),  _) 

— >  -i(0  (  member_acceptkey(M,  GCKS,  (G,  K'G),  _) 

A  O  (  gcks_createkey(  GCKS,  (),  (G,  K'G),  _) 

A  <$’gcks_createkey(GCA,S,  (),  (G,  KG),  _))) 

Note  that  we  do  not  specify  recency  freshness  as  a  re¬ 
quirement  for  the  push  protocol.  This  can  be  achieved,  if 
desired,  by  including  timestamps  in  the  Security  Associa¬ 
tion,  but  this  is  not  a  requirement  of  GDOI. 

4.4.4  Freshness  of  a  Member’s  Key  Request 

We  now  consider  a  freshness  requirement  from  the  GCKS’s 
point  of  view.  When  the  GCKS  responds  to  a  member’s  re¬ 
quest  with  a  key,  it  must  be  sure  that  this  is  a  new  request, 
not  a  replay  of  some  old  request.  Since  a  member’s  request 
contains  a  nonce  which  is  intended  to  be  unique,  we  make 
this  into  a  requirement  that  a  GCKS  should  not  have  pre¬ 
viously  distributed  a  key  to  that  member  using  that  nonce. 


Note  that  this  freshness  requirement  can  only  be  guaran¬ 
teed  for  an  honest  member,  since  there  is  nothing  prevent¬ 
ing  a  dishonest  member  from  replaying  an  old  request  and 
then  participating  in  the  protocol  to  obtain  a  key.  Since 
honest  members  are  the  only  ones  we  are  interested  in  pro¬ 
tecting  anyway,  this  is  not  a  problem  for  us.  However,  we 
need  a  way  of  distinguishing  between  honest  and  dishonest 
members.  We  do  this  by  borrowing  a  trick  from  the  NRL 
Protocol  Analyzer  specification  language,  and  referring  to 
principals  as  member(M,  H)  where  H  is  a  variable  that  can 
be  instantiated  to  honest  or  dishonest.  At  this  point  we  are 
only  interest  in  member)./!/,  honest): 

gcks_sendpul  I  key  (GCAS,  Mh,  {Ka,  Nm  ,  NGM  ,G,  KGM),  -) 

— >  OgcksJosepairwisekey(GGAS,  (),  (A/,,  KGm),  — ) 

V-i <$,gcks_send pul lkey( GCAS,  Mh,  {K'g,  Nm ,  Nf.M,G,  KGM),  _) 

where  Mh  =  member)/!/,  honest). 

4.4.5  Freshness  of  Proof  of  Possession 

Freshness  requirements  for  Proof  of  Possession  are  more 
similar  to  two-party  freshness  requirements  than  some  of 
the  others  we  have  visited.  Since  POPs  are  computed  on 
nonces  supplied  by  sender  and  receiver  we  require  that,  if  a 
principal  accepts  a  POP  for  two  nonces,  then  it  should  not 
have  accepted  it  previously.  Since  the  POP  is  computed  on 
the  sender’s  and  receiver’s  nonces,  this  can  be  enforced  by 
requiring  that  the  GCKS  does  not  engage  in  a  sendpullkey 
event  based  on  the  same  nonces  twice,  and  that  a  member 
does  not  engage  in  an  member_acceptpullkey  event  based  on 
the  same  nonces  twice.  Note  that  the  GCKS’s  freshness 
requirement  is  similar,  but  somewhat  stronger  than,  the  re¬ 
quirement  for  freshness  of  a  member’s  key  request;  it  is  not 
dependent  on  the  pairwise  key  being  uncompromised. 

gcks_sendpullkey(  GCKS,  Mh,  (KG,NM,  Ngm,G,  Kgm),_) 

— >-’Ogcks_send pul lkey( GCAS,  Mh,  ( K'a ,  Nm,Ngm,G,  K'gm ),  _) 

member_acceptpullkey(A/,  GCKS,  {Kg,  Nm,  Ngm,  G,  Kgm),  -) 
^-■Omember_acceptpullkey(Af,  GCKS,  (Kf,,  Nm,  Ngm,  G',  KgM),  _) 
where  again  Mh  =  member(M,  honest). 

4.5  Secrecy  Requirements 

GDOI  has  one  basic  secrecy  requirement,  that  keys  should 
only  be  learned  by  members  of  the  group.  However,  we  may 
want  to  put  other  conditions  on  this  requirement.  For  ex¬ 
ample,  we  may  require  that  new  members  should  not  have 
access  to  old  keys  ( backward  access  control),  and  that  ex¬ 
pelled  members  will  not  have  access  to  any  keys  generated 
after  they  were  expelled  ( forward  access  control).  GDOI 
also  allows  for  an  option  that  provides  a  degree  of  protec¬ 
tion  against  compromise  of  pairwise  keys;  it  allows  for  the 
optional  use  of  DifHe-Hellman  to  assure  perfect  forward  se¬ 
crecy:  if  a  pairwise  key  is  stolen,  then  the  intruder  should 
only  be  able  to  learn  key  encryption  keys  distributed  after 
the  event. 

As  we  can  see,  the  different  secrecy  requirements  are  not 
quite  orthogonal,  and  they  can  interact  with  each  other  in 
different  ways.  For  example,  one  would  not  want  to  waste 
time  with  perfect  forward  secrecy  if  one  did  not  also  have 
backwards  access  control.  In  general,  it  is  assumed  that  it 
is  more  likely  that  a  dishonest  member  will  join  the  group 
than  that  a  pairwise  key  shared  between  only  two  principals 
will  be  stolen.  So  it  makes  little  sense  to  use  perfect  forward 
secrecy  to  protect  old  keys,  if  they  could  be  compromised 


by  having  a  group  key  distributed  to  a  dishonest  principal. 
Likewise,  requirements  such  as  forward  and  backward  access 
control  should  not  only  govern  the  effects  of  the  distribution 
of  keys,  but  other  events  such  as  the  stealing  of  keys.  For 
example,  if  members  should  no  longer  have  access  to  new 
keys  after  leaving  the  group,  then  an  intruder’s  stealing  a 
key  should  not  give  it  access  to  subsequent  keys  either. 

Our  solution  to  this  problem  is  to  define  a  number  of  con¬ 
ditions  describing  sequences  of  events  that  define  the  sit¬ 
uation  under  which  an  intruder  might  learn  a  key.  These 
conditions  can  then  be  mixed  and  matched  to  put  together 
the  appropriate  requirement.  We  can  then  use  the  NPA- 
TRL  logic  to  reduce  the  requirements  to  normal  form,  when 
necessary. 

In  the  remainder  of  this  section,  we  describe  the  various 
sequences.  These  include  five  “base  cases”  that  describe 
some  simple  sequences  of  events  that  could  lead  to  key  com¬ 
promise,  as  well  as  two  recursively  defined  cases  that  de¬ 
scribe  forward  access  control  without  backward  access  con¬ 
trol,  and  vice  versa.  We  also  give  several  examples  showing 
how  the  various  cases  can  be  combined  to  produce  different 
types  of  requirements. 

4.5.1  The  Base  Cases 

The  five  base  cases  are  as  follows: 

BC1  (Ka,G): 

gcks_losegroupkey(GCi:fS,  (),  (G,  Kq),  _) 

This  describes  the  a  group  key-encryption  key  being 
stolen. 

BC2a(AG,G): 

0(  gcks_sendpushkey(GGi:fS,  (),  (G,  Kq,  K'g),  N) 

A  0gcks_sendpullkey(GGAS,  Md,  (G,  _.  NGM,  K"KGM),  -)) 
A  -.0(  gcks_sendpushkey(GCKS,  (),  (G,  Ka,  K'a).  N) 

A  ^gcks_cancel( GCKS,  Md,  (G,  NGM),  _)) 

where  Md  =  member(AA dishonest).  This  describes  a 
group  key  being  distributed  while  a  dishonest  member 
is  in  the  group.  Note  that  it  is  in  two  parts.  The  first 
says  that  the  dishonest  member  has  joined  the  group; 
the  second  says  that  the  member  has  not  left  it  yet.  In 
order  to  take  care  of  the  possibility  of  multiple  joinings 
and  leavings,  we  give  both  join  and  leave  the  same 
index  NGm,  which  uniquely  identifies  M’s  joining  the 
group. 

BC2b(AG,G): 

Ogcks_sendpullkey(  GCKS,  Md,  (G,  NGM,  KG,KGM),  -) 

for  Md  =  member(M,  dishonest).  This  describes  a  group 
key  KG  being  distributed  to  a  dishonest  member  via 
a  pull  protocol,  that  is,  the  dishonest  member  is  being 
admitted  to  the  group. 

BC3a(A'G,  G): 

OgcksJosepairwisekey(GGAS,  (),  (M,  KGm),  —) 

A  Ogcks_sendpullkey(GGA5,  M,  (G,  _,  KG,KGM),  _) 

This  describes  the  result  of  a  pairwise  key  being  lost 
and  a  key  being  sent  using  that  pairwise  key. 


BC3b(A'G,  G): 

0  (  gcks_sendpjllkey(GGA5',M,(G,_,_,  KG,KGM),_) 

A  0gc  ks  Jose  pairwise  key  (  GCKS ,  (),  (M,  KG  xi )  ■  _)) 

This  describes  a  pairwise  key  being  lost  and  a  key  being 
sent  using  that  pairwise  key  after  the  pairwise  key  is 
lost. 

4.5.2  The  Recursive  Cases 

There  are  two  recursive  cases.  The  first  describes  an  in¬ 
truder  learning  an  old  key  after  a  later  key  has  become  cur¬ 
rent.  The  second  describes  the  intruder  learning  a  key  be¬ 
fore  another  key  expires.  We  call  these  two  cases  “backward 
inference”  and  “forward  inference.” 

BI(AG,  G) 

0learn(P,  (),(Ag,G),_) 

A  0(  gcks_createkey(  GCKS ,  (),  (G,  KG),  _) 

A  <0>gcks_createkey(GGA5:,  (),  (G,  K'G ),  _)) 

Note  that  when  a  new  key  is  sent,  the  old  key  expires. 
And,  we  assume  any  (non-initial)  key  is  sent  in  a  push- 
key  message  as  soon  as  it  is  created.  Thus  Bl  for  AG 
describes  an  intruder  learning  a  key  A'G  that  became 
current  after  a  key  KG  was  current. 

FI(Ag,G) 

Olearn(P,(),(A",G),_) 

A  0(  gcks_sendpushkey(GGAS,  (),  (G,  KG,  K'G),  _) 

A  Ogcks_sendpushkey(GGAS,  (),  (G,  KG,  K'G),  _)) 

FI  describes  an  intruder  learning  a  key  I\G  that  expired 
before  a  later  key  A'G  was  generated. 

Backward  Inference  will  be  used  to  specify  forward  ac¬ 
cess  control  without  backward  access  control:  If  an  intruder 
learns  a  key  KG,  then  BI(A'g,G)  will  be  listed  among  the 
set  of  possible  paths  to  that  event,  but  not  FI(Ag,G),  that 
is,  the  intruder  may  have  learned  KG  as  a  result  of  learning 
a  key  K'G  that  expired  previously  to  A'G,  but  not  a  key  AG 
that  was  generated  after  KG  expired.  Similarly,  Forward 
Inference  will  be  used  to  specify  backward  access  control 
without  forward  access  control:  if  an  intruder  learns  a  key 
KG,  then  FI(A'g,G)  will  be  listed  among  the  set  of  of  pos¬ 
sible  paths  to  that  event,  but  not  BI(A'g,G). 

We  note  that  there  appear  to  be  some  major  changes  from 
the  original,  informal,  definition  of  forward  and  backward 
access  control.  The  original  definition  put  the  requirement 
on  the  knowledge  of  any  group  member,  not  on  the  intruder. 
Also,  the  original  requirement  discussed  a  member  learning  a 
key  as  a  result  of  joining  the  group,  while  we  simply  consider 
the  results  of  the  intruder  learning  a  key  without  specifying 
how  it  was  learned. 

Our  rationale  for  changing  the  focus  from  member  to  in¬ 
truder  can  be  expressed  in  two  steps.  In  the  NRL  Protocol 
Analyzer  model,  we  assume  that  dishonest  group  members 
can  do  everything  honest  group  members  do  and  more,  since 
honest  members  can  only  obey  the  rules  of  the  protocol. 
Thus  any  conditions  on  a  dishonest  member’s  learning  a 
key  should  also  hold  for  an  honest  member.  Secondly,  we 
assume  that  all  dishonest  members  share  information  with 
the  intruder,  so  that  any  conditions  on  the  intruder’s  learn¬ 
ing  a  key  would  imply  the  same  condition  for  a  dishonest 
member  learning  that  information. 


4.5.3  Sample  Requirements 
In  this  section,  we  show  how  the  various  “cases”  can  be 
combined  into  requirements. 

Weak  Secrecy 

The  weakest  form  of  secrecy  requirement  simply  requires 
that  the  protocol  should  protect  against  key  compromise 
given  the  most  benign  assumptions  possible:  that  is,  that 
neither  pairwise  or  key  encryption  keys  have  been  lost,  and 
no  dishonest  members  have  even  joined  the  group.  This  can 
be  described  in  terms  of  three  separate  conditions: 

learn (P,  (),  (AG,  G),  _) 

->  BC1  (K'a,G)  V  BC2b(A(j,G)  V  BC3a(A(j,G) 

In  other  words,  the  intruder  should  not  learn  a  key  Kg  for  G 
unless  some  group  key  has  previously  been  lost,  a  dishonest 
member  joined  the  group  at  some  time,  or  a  pairwise  key 
that  was  used  to  distribute  a  group  key  was  stolen,  either 
before  or  after  being  used. 

Strong  Secrecy 

We  can  also  use  the  base  cases  to  formulate  the  strongest 
type  of  secrecy  possible.  In  strong  secrecy,  the  intruder 
learns  a  key  Kg  only  if  Kg  is  lost,  a  dishonest  member 
received  Kg,  either  when  it  joined  the  group  or  while  it  was 
a  member  of  the  group,  or  if  a  pairwise  key  was  stolen  and 
used  to  distribute  Kg-  We  may  or  may  not  wish  to  require 
perfect  forward  secrecy. 

Here,  for  example,  is  strong  secrecy  with  perfect  forward 
secrecy: 

learn(P,  (),  (AG,  G),  _) 

-►  BC1(Ag,G)  V  BC2a(AG,G)  V  BC2b(A'G,G) 

V  BC3b(AG,  G) 

Forward  Access  Control 

Forward  access  control  (without  backward  access  control) 
can  be  thought  of  as  strong  secrecy  together  with  added 
condition  of  backward  inference:  An  intruder  can  learn  a 
key,  not  only  if  the  key  was  lost,  distributed  to  a  dishonest 
member,  or  distributed  using  a  lost  pairwise  key,  but  if  the 
key  became  current  before  the  intruder  learned  a  later  key, 
e.g.,  because  a  dishonest  member  joined  the  group.  We  do 
not  include  perfect  forward  secrecy,  since  protecting  against 
old  keys  being  compromised  as  a  result  of  a  stolen  pairwise 
key  makes  no  sense  if  the  keys  could  be  learned  as  a  result 
of  a  dishonest  member  joining  the  group  at  any  point: 

learn (P,  (),  (AG,  G),  _) 

->  BC1(Ag,G)  V  BC2a(A"G,  G)  V  BC2b(A"G,  G) 

V  BC3a(AG,  G)  V  BI(Ag,G) 

Backward  Access  Control 

Backward  access  control  (without  forward  access  control) 
can  be  specified  similarly  to  forward  access  control,  except 
that  we  replace  backward  with  forward  inference.  We  can 
require  perfect  forward  secrecy  or  not.  Here,  for  example,  is 
backward  access  control  without  forward  access  control  but 
with  perfect  forward  secrecy: 

learn (P,  (),  (AG,  G),  _) 

->  BC1(Ag,G)  V  BC2a(A"G,  G)  V  BC2b(A"G,  G) 

V  BC3b(AG,  G)  V  FI(Ag,G) 


If  we  wanted  to  omit  the  perfect  forward  secrecy  requirement 
we  would  substitute  BC3a(A'G,G)  for  BC3b(A'G,G). 

In  appendix  A  we  show  how  to  put  the  requirements  for 
Forward  and  Backward  Access  Control  into  normal  form. 

5.  CONCLUSIONS 

We  have  presented  a  set  of  formal  security  requirements 
for  the  group  protocol  GDOI.  In  developing  these  require¬ 
ments  we  learned  much,  not  only  about  GDOI  itself,  but 
about  the  nature  of  requirements  for  open-ended  crypto¬ 
graphic  protocols.  This  has  motivated  us  to  develop  the 
NPATRL  requirements  language  into  a  full-scale  logic  that 
can  be  used  to  reason  about  and  simplify  requirements  as 
well  as  specify  them. 

As  this  paper  is  being  written,  we  are  currently  using  the 
NRL  Protocol  Analyzer  to  verify  that  GDOI  satisfies  these 
requirements.  This  in  turn  may  lead  to  a  revision  or  im¬ 
provement  of  the  requirements  as  we  discover  more  by  our 
analysis.  We  have  also  been  able  to  use  our  formalization  of 
the  requirements  to  discover  and  suggest  improvements  to 
GDOI.  These  suggestions  have  been  incorporated  into  later 
versions  of  the  draft.  Thus,  we  have  already  found  these 
requirements  to  be  useful. 
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APPENDIX 

A.  REMOVING  RECURSION 

In  this  appendix  we  show  how  we  use  the  NPATRL  logic 
to  remove  recursion  from  the  requirements  for  forward  and 
backwards  access  control.  Removing  recursion  is  not  only 
desirable  from  the  point  of  view  of  the  NRL  Protocol  Ana¬ 
lyzer,  but  also  because  a  recursively  defined  condition  may 
cause  an  infinite  regression  in  other  model  checkers  and  the¬ 
orem  provers. 

We  present  only  the  proof  for  backward  access  control; 
that  for  forward  access  control  is  similar. 

Lemma  1. 

The  backward  access  control  condition  BAC (I\g,G)  = 

learn(P,  (),  (Kq,  G),  _) 

->  GBC1  (Ag,G)  V  0BC2a(AG,G)  V  0BC2b (KC,G) 

VOBC3a (Ag,G)  V  GFI (Kg,G) 

is  equivalent  to  the  conditions  NRFAC(Ag,G)  = 

learn (P,  (),  (AG,  G),  _) 

->  GBC1(Ag,G)  V  0BC2a(AG,G)  V  0BC2b (KC,G) 
VOBC3a (Ag,G)  V  GNRFI(Ag,G), 

where  NRFI(Ag,G)  = 

(BC1(A" ,  G)  V  BC2a(A" ,  G)  V  BC2b(A" ,  G)  V  GBC3a(A" ,  G)) 
A  gcks-sendpushkey^CAS1,  (),  (G,  Kq,  Kq),  _) 

A  Ogcks_send  push  key  ( GCKS,  (),  (G,  Kq,  Kq),  _). 

Proof.  We  make  use  of  the  following  facts  that  follow 
from  the  NPATRL  axioms.  For  reasons  of  space,  we  leave 
the  proofs  as  an  exercise  to  the  reader: 

1.  0(A  A  B)  — >  OA  A  OB; 

2.  OOA  — >  O A,  and; 

3.  (A  A  OB)  A  (G  A  O A)  — >  G  A  OB. 

For  purposes  of  of  this  proof,  let  BC(A',  G)  = 

GBC1(A,G)  V  0BC2a(A,G)  V  OBC2b(A',G)  V  0BC3a(A,G). 


We  need  to  show  that  “learn(P,  (),  (A,  G),  _)  — ►  BC(A,  G)  V 
ONRFI(A',  G)”  is  logically  equivalent  to  “learn(P,  (),  (A,  G),  _) 
— >  BC(A,  G)  V  OP7(AT,G)”.  It  is  clear  that  “0BC(A,G)  V 
GNRFI(A,G)”  implies  “GBC(A,G)  V  OFI(K, G)” ,  since 
“(BC1(AT,G)  V  BC2a(Al,  G)  V  BC2b(A'l,G)  V  BC3a(A'l,G)” 
implies  “learn(P,  (),  (A'1,G),  _)”. 

We  prove  the  implication  in  the  other  direction  by  induc¬ 
tion  on  the  age  of  K 1 .  Suppose  that  K  is  the  first  key  used 
by  the  GCKS  for  G.  Then,  since  there  is  no  K 1  that  was 
distributed  before  K,  neither  “FI(A,G)”  nor  “NRFI(A\  G)” 
holds,  and  so  “BC(A',  G)  V  FI(A,  G)”  is  trivially  equivalent 
to  “BC(A,  G)  V  NRFI(K,  G)”. 

Suppose  that  now  that  the  result  holds  for  the  fc’th  key 
K„  used  by  the  GCKS,  for  all  k  <  n.  Let  Kn  by  the  n’th 
key.  Then 

learn(P,  (),  Kn,  G),  _) 

-»•  GBC(A„,G) 

V  (  learn(P,(),(AT,G),_) 

A  gcks_sendpushkey(GCA5l,  (),  (G,  Kn,  K2),  _) 

A  Ggcks_sendpushkey(  GCKS,  (),  (G,  Kk,  A3),  _)), 

for  some  k.  Since  Kk  was  used  before  Kn,  we  have  k  <  n, 
and  by  the  induction  hypothesis  we  get 

learn(P,  (),  (An,  G),  _) 

—  BC(An,G) 

V0(  0(  BC(A;,G) 

A  gcks_sendpushkey(GCAS,  (),  (G,  Kk,  A'"),  _) 

A  0gcks_sendpushkey(GGA£,  (),  (G,  Aj,  A""),  _))) 
A  (  gcks_send  push  key  ( GCKS,  (),  (G,  A„,  A'),  _) 

A  gcks_send  push  key  ( GCKS,  (),  (G,  Kk,  A'"),  _)))). 

Using  the  facts  “0(A  A  B)  — >  QA  A  <$>B”,  that  “OOA  — > 
OA”,  and  that  “(A  A  OB)  A  (G  A  OA)  —>  C  A  OB”,  we 
have 

learn(P,  (),  Kn,  G),  _) 

-*•  BC(An,  G) 

VO(  BC(A'i,G) 

A  gcks_sendpushkey(GGAS,  (),  (G,  A„,  K'"),  _) 

A  Ogcks_sendpushkey(  GCKS,  (),  (G,  A;,  K'"'),  _)), 

which  is  the  result  we  need.  □ 


Lemma  2. 

The  forward  access  control  condition  FAC(A'g,G)  = 
iearn(P,  (),  (Ag,  G),  _) 

->  0BC1(Ag,G)  V  0BC2a(AG,G)  V  0BC2b(AG,G) 

V  0BC3a(AG,  G)  V  OBI(Ag,G) 

is  equivalent  to  the  conditions  NRBAC(Ag,G)  = 

learn(P,  (),  (Ag,  G),  _) 

OBC1(Ag,G)  V  0BC2a(AG,G)  V  OBC2b(AG,G) 
VOBC3a(AG,G)  V  ONRBI(Ag,G), 

where  NRBI(Ag,G)  = 

(BC1(Ag,  G)  V  BC2a(AG,  G)  V  BC2b(AG,  G)  V  0BC3a(AG,  G)) 
A  gcks_sendpushkey(GGAS,  (),  (G,  Kq,  Kq),  _) 

A  Ogcks_sendpushkey(  GCKS,  (),  (G,  Kq,  Kq),  _). 


Proof.  The  proof  is  the  same  as  for  backward  access 
control,  except  the  base  induction  case  is  the  most  recent 
key  instead  of  the  first  key,  and  the  induction  is  on  distance 
from  the  most  recent  key  instead  of  on  distance  from  the 
earliest  key.  □ 


